Repository navigation
Bump the manifests to 26.11.0 - #270
vpetersson-bot wants to merge 2 commits into
Conversation
master has carried 2026.10.0 since #268, but no tag was cut for it, so the newest release is still v1.6.1 from July. A new month resets MICRO, so the release that ships now is 2026.11.0. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
There was a problem hiding this comment.
Copilot encountered an error: Your billing is not configured or you have Copilot licenses from multiple standalone organizations or enterprises. To use premium requests, select a billing entity via the GitHub site, under Settings > Copilot > Features.
514sid
left a comment
514sid
left a comment
There was a problem hiding this comment.
We're not using the full year. The version should be 26.11.0, and the full year is written down in three places, so all three need to change:
src/manifest-chrome.jsonandsrc/manifest-firefox.jsonshould be26.11.0.CONTRIBUTING.md(lines 37-72) documentsYYYY.M.MICROwith2026.9.0/v2026.9.0as examples, and the release steps usevYYYY.M.MICRO. That's where #268 and this PR got the format from, so it needs to becomeYY.M.MICRO(26.9.0,v26.11.0) in this PR, or the next bump will reintroduce it.- The release commands in the description (
git tag -a v2026.11.0,gh release create v2026.11.0), the title and the branch namerelease/2026.11.0. Those commands are what will get pasted when tagging.
Switching now costs nothing, since no CalVer tag has ever been cut: the newest tag is still v1.6.1, so the stores have never seen 2026.x. Once a v2026.x tag ships we're stuck with it, because Chrome Web Store versions can only increase and 26 sorts below 2026. 26.11.0 is still above 1.6.1, so leaving 1.x is fine.
Related: build.yaml (30-37) and test.yaml (27-34) still write the tag's version over the manifest during the build, so the tag decides what ships, not the manifests. Tagging v2026.11.0 from the current description would ship that. The tag-vs-manifest check left as a follow-up in #266 is what would catch this; it would be good to get it landed by someone with workflow scope before or alongside this release.
There was a problem hiding this comment.
Copilot encountered an error: Your billing is not configured or you have Copilot licenses from multiple standalone organizations or enterprises. To use premium requests, select a billing entity via the GitHub site, under Settings > Copilot > Features.
vpetersson-bot
changed the title
|
Agreed, done in 1dae436:
Noted the |
514sid
left a comment
514sid
left a comment
There was a problem hiding this comment.
Commit 1dae436 ("Use a two-digit year: bump the manifests to 26.11.0") is unsigned, so GitHub shows it as Unverified, and master requires signed commits. 4ce0211 is signed and verified. Please re-sign 1dae436 (or squash both into one signed commit) and force-push the branch. The content is fine as is; nothing else needs to change.
The stores have never seen a 2026.x version (the newest tag is v1.6.1), so switch to YY.M.MICRO now, before a four-digit tag makes it permanent. CONTRIBUTING.md documented YYYY.M.MICRO, which is where the 2026.x numbers came from, so update it to match. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1dae436 to
e8c149d
Compare
Bumps
src/manifest-chrome.jsonandsrc/manifest-firefox.jsonto26.11.0, and switches the documented CalVer scheme inCONTRIBUTING.mdfromYYYY.M.MICROtoYY.M.MICRO.Why
#268 put
2026.10.0in the manifests on 19 October, but no tag followed, so the newest release is stillv1.6.1from July. CalVer resets MICRO on a new month, so the version that ships now is26.11.0rather than a back-dated October number.We use a two-digit year. No
v2026.xtag has ever been cut, so switching costs nothing now; once one ships we'd be stuck with it, because Chrome Web Store versions only increase and26sorts below2026.26.11.0is still above1.6.1.CONTRIBUTING.mdis where the four-digit format came from, so it changes here too.The branch is still named
release/2026.11.0: renaming it is blocked by the org rulesets. It has no effect on what ships.What ships since v1.6.1
Nothing has landed since #268, so this is the same content reviewed for the October release:
Release once merged
build.yamlandtest.yamlstill write the tag's version over the manifests during the build, so the tag decides what ships. It must equal the manifests:The tag-vs-manifest check left as a follow-up in #266 would catch a mismatch; it needs someone with
workflowscope to land it.🤖 Generated with Claude Code